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NETWORK RESOURCE CONTROL 

Technical Field 

The present invention relates to a method for controlling the rate of data transmitted 
5 to a user on a communications link, and in particular to a method of resource control 
wherein resource requests from a user to a service provider are determined in 
response to the amount of congestion on the communications link. 

Background to the Invention and Prior Art 

10 The last two decades have seen the introduction of so-called 'integrated' networks, 
such as asynchronous transfer mode (ATM) and Internet Protocol (IP) networks, 
which are designed to carry both computer communications and telephony. The 
capacity of those networks needs to be allocated between users who require a 
constant bit-rate for the duration of a communication (e.g. telephone users), those 

15 who can tolerate some variation in the bit-rate supplied to them by the network (e.g. 
those transferring web-pages, software or e-mails), and those users who can tolerate 
less variation in the bit-rate supplied to them by the network (e.g. those transferring 
. video clips or other real time applications). 

To deal with different user's requirements, integrated networks offer their users the • 

20 ability to specify which service they wish to receive from the network (which, being 
an integrated network, can offer a plurality of different services). This specification 
can be made once at the start of a communication (the normal procedure in networks 
offering a connection-oriented service, such as ATM networks) and / or repeatedly 
during a communication. 

25 

As mentioned, an Internet Protocol network is one type of integrated network. An IP 
network can offer a constant bit-rate service type (using the Resource Reservation 
Protocol (RSVP)), and a best efforts service type. Another service type gives packets 
sent by one class of users priority over packets sent by another class of user. Using 
30 RSVP, a user can additionally specify the amount of bandwidth he or she wishes to 
have available. 




Where a person has to make such a service specification many times because he or 
she is involved in a number of different communications and/or has to make a 
plurality of service specifications during a communication, it is beneficial if that 
specification is made on that person's behalf by a computer programmed to act as 
5 that person's agent, 

The present invention concerns how the computer acting as an agent determines the 
data rate request for the user. 

10 During the last five years not only has the amount in Internet traffic increased 
dramatically, but there has also been a significant diversification in the type of traffic 
flowing through computer networks. Until fairly recently, file transfer, email and 
simple web traffic formed the almost all the data flows on the Internet. Now 
applications may include multi-party and/or multi media data transmission. Such 

15 applications include "real-time" audio and video, interactive games, instant 
messaging, multi-party virtual worlds, network games, auctions, audio and video- 
conferencing and IP telephony. 

In view of the increase in data transmission, efficient control and management of the 
20 network resources is becoming increasing important. One of the problems faced by 
network users and service providers is congestion, a situation in which there is too 
much data for the network to handle. The consequence of which is delays or even 
loss of data. 

25 Traditionally, rate control in the Internet is taken care of by the Transmission Control 
Protocol (TCP). TCP is described in many references places, for example, "Fred 
Halsall, Data communications, computer networks and open systems, 6th ed., 
Addison-Wesley, 1995. TCP is a window based rate control algorithm, i.e. window 
based rate control is achieved by limiting the amount of data that can be in the 

30 network at any one time, TCP is stable and normally makes fairly efficient use of the 
available bandwidth, and distributes network resources fairly between different users. 
For file transfer and email, TCP performs well because, provided the file or email 
arrives within a reasonable time at its destination, it is not important at which rate 




the data was transmitted. However, TCP rate control gives rise to fluctuations in the 
transfer rate that are unacceptable for applications where the rate of data 
transmission is important, for example, real time applications, such as video and 
audio streaming. The reason for this is that If a single packet is lost the congestion 
window is halved. Further TCP guarantees that lost packets will be retransmitted 
until they arrive at the receiver. For some applications including real-time multimedia 
applications , this is not necessary. 

Problems with rate fluctuations which occur in networks running TCP have made it 
necessary to develop alternative rate control algorithms. It is believed that in time 
TCP will become a less preferred option, as it becomes less able to deal with the 
greater variety of services users demand. 

Further, as congestion on the Internet increases, network managers are looking for 
alternative ways to manage it. Also, multimedia multi-party internet protocol (IP) 
applications, such as those mentioned above, can be very demanding in terms of 
their Quality of Service (QoS) requirements. Standards are being developed to ensure 
that network resources can be applied where they are most needed. However, 
problems still surround how the demand for different classes of QoS should be 
managed. 

One solution to this problem may be congestion based pricing. The underlying idea 
being to charge users or, on a more abstract level, to charge applications. The charge 
may be either in terms of real currency or in some other terms, for example fictional 
currency. The charge is made for the network resources used. Also the charge 
increases depending on the level of network congestion. When bandwidth becomes 
scarce, the charge will increase, when congestion reduces the charge is decreased. 
This gives users, or applications, the incentive to back off the network at times of 
network congestion. Congestion based pricing is discussed by P.P. Kelly in "Charging 
and rate control for elastic traffic", European Transactions on Telecommunications, 
vol.8, pp33-37, January 1997. 

Conventional rate control techniques are based on variables which reflect network 
performance, such variables include packet loss or roundtrip time. Price based 
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approaches exploit "shadow prices" (an expression borrowed from economics which 
is applied to situations where actual prices cannot be charged, or where actual prices 
do not reflect the real sacrifice made when some activity is pursued. Shadow prices 
are used in valuing any item, such as a network resource, which is implicitly rationed 
5 or constrained in some way.) and user determined policies that specify how much the 
user values the data rate they get from the network. One way of expressing this 
variable is the user's willingness to pay for a particular service. 

One such priced based technique for managing congestion is discussed in "F P Kelly, 
10 A K Maulloo, and D K H Tan, Rate control for communication networks: Shadow 
prices, proportional fairness and stability, Journal of the Operational Research Society 
49 (1998), no. 3, 237-252". In this paper, Kelly et al propose an "equation based 
algorithm". Equation based algorithms are so called because they differ from window 
based algorithms, such as TCP, in that the sending rate is determined directly 
15 (without any other external constraints) using a mathematical equation. Contrary to 
window based rate control, equation based rate control does not place an explicit 
limit on the amount of outstanding data (data that has left the sender, but has not 
arrived at the receiver yet). At present, TCP, a window based algorithm, is not able 
to support such alternative equation based algorithms for rate control. 

20 

The equation based rate control algorithm proposed by Kelly et al -is known as the 
"primal" algorithm. The primal algorithm determinies the request for a data rate which 
a user sends to his service provider, when requesting a download of data. The primal 
algorithm is an adaptive system which takes user determined parameters, such as the 

25 user's willingness to pay for a service together with network manager determined 
parameters, such as the price charged by the resource per unit flow, and network 
determined parameters, such as the transfer rate of the flow along a particular route 
and the congestion price, to determine the sending rate request which the user sends 
to his service provider, 

30 The primal algorithm has been shown to be stable. However, the rate of 
convergence, that is the rate at which the algorithm reaches a stable rate, is a 
particular problem with the primal algorithm. This causes problems in particular, at 
the beginning of a download, where it takes the primal algorithm too long to go from 
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a very low data rate to the desired data rate, and in situations where congestion is to 
be avoided, where the user desires a relatively low data rate, with however, little 
variation. 

5 The present invention provides a solution to the problems identified above with 
respect to resource control in data transmission. 

Summary of the Invention 

According to the present invention, there is provided a method of controlling the rate 
10 of data transmission from a source of data to a user via a communications link, 
wherein processing means are provided to generate a signal representing a rate 
request which will be used in determining the rate at which data will be transmitted 
from the source to the user, said processing means generating the signal by carrying 
out the steps of: 

1 5 obtaining an indication of the amount of congestion on said communications link, 

selecting a value indicative of the user's willingness to pay for a given transmission 
data rate, and 

20 determining the rate to be requested as a function of the indication of the amount of 
congestion and the user's willingness to pay weighted by a variable parameter, the 
processing means thereafter communicating the signal to the source of data and the 
rate of the data transmission from the data source to the user then being controlled 
on the basis of the signal. 

25 

The inventors have realised that by weighting a function of the user's willingness to 
pay and an indication of the congestion to determine a data rate to be requested, the 
data rate requested can be controlled more efficiently. This enables improved 
allocation of resources of the network over prior art systems. 

30 

Preferably, the rate to be requested is determined using the following iterative 
equation: 




Xn+1 = Xn + delta* kappa * Xn^(W - Xn*//) 

where Xn is the data transmission rate (bits per second) as calculated at an nth 
iteration; and Xn-fi is the rate to be determined; Xn*/j is the charge to the user 
5 indicative of amount of congestion and is the product of Xn and congestion charge // ; 
w is the willingness to pay ; delta is the time elapsed between two iterations; kappa 
is a constant gain parameter; and (xi) is a parameter whose value is set depending 
on the indication of congestion or the user's willingness to pay. 

10 This has the advantage of enabling the rate controller to adopt different policies 
depending on the user's preferences and the network conditions. The data rate 
requests will have different values depending on the users preferences and the 
network conditions. The possible policies differ by their reactivity speed to sudden 
changes to the congestion level. 

15 

According to a further aspect of the present invention, there is provided a rate 
controller for controlling the rate of data transmission from a source to a user via a 
communications link, said rate controller including processing means for generating a 
signal representing a rate request which will be used in determining the rate at which 
20 data will be transmitted from the source to the user, said processing means including 
means for obtaining an indication of the amount of congestion on said 
communications link, 

selecting means for selecting a value indicative of the user's willingness to pay for a 
given transmission data rate, 
25 determining means for determining the rate to be requested as a function of the 
indication of the amount of congestion and the user's willingness to pay weighted by 
a variable parameter, the processing means further including means for 
communicating the signal to the source, wherein the rate of the data transmission 
from the source to the user is controlled on the basis of the signaL 

30 

According to a further aspect of the present invention, there is provided a method of 
controlling the rate of data transmission from a source of data to a user via a 
communications link, wherein processing means are provided to generate a signal. 



representing a rate request which will be used in determining the rate at which data 
will be transmitted from the source to the user, said processing means generating the 
signal by carrying out the steps of: 

obtaining an indication of the amount of congestion on said communications link, 
5 selecting a value indicative of the user's willingness to pay for a given transmission 
data rate, 

determining the rate to be requested on the basis of the ratio of said value to said 
indication of the amount of congestion on said communications link. 

10 The inventors have realised that by assessing the ratio of a user determined 
parameter and the indication of the congestion on the network to determine a data 
rate request, the rate of convergence of the system is dependent only on the 
congestion level. This has the advantage that the rate control method does not affect 
the stability of the network. 



15 



20 



25 



Preferably, the method of controlling the rate of data transmission determines the 
rate to be requested in accordance with the following equation; 



f 

. 



where Xn is the data transmission rate (bits per second) as calculated at an nth 
iteration and Xn+i is the rate to be determined; ii is the congestion charge indicative 
of amount of congestion; w is the willingness to pay; delta is the time elapsed 
between two iterations; and kappa is a constant gain parameter. 



Further according to another aspect of the present invention, there is provided a rate 
controller for controlling the rate of data transmission from a source to a user via a 
communications link, said rate controller including processing means for generating a 
signal representing a rate request which will be used in determining the rate at which 
30 data will be transmitted from the source to the user, said processing means including 
means for obtaining an indication of the amount of congestion on said 
communications link. 
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selecting means for selecting a value indicative of the user's willingness to pay for a 
given transmission data rate, 

determining means for determining the rate to be requested as on the basis of the 
ratio of the user's willingness to pay to said indication of the amount of congestion 
5 on said communications link, the processing means further including means for 
communicating the signal to the source, wherein the rate of the data transmission 
from the source to the user is controlled on the basis of the signal. 

Both apparatuses summarised above are preferably embodied in a general purpose 
10 computer, suitably programmed- 

This invention also extends to a computer programmed to perform the method of the 
invention, and to a computer program product loadable into the internal memory of a 
digital computer, comprising software code portions for performing the steps of the 
1 5 method of the invention, when said product is run on a connputer. 

Brief Description of the Drawings 

By way of example only, specific embodiments of the present invention will now be 
20 described with reference to the accompanying Figures in which: 

Figure 1 shows schematically the basic components of a general purpose computer 
disposed In a network connected to a content provider, capable of performing the 
invention; 



Figures 2a and 2b show demand functions; 

Figure 3 illustrates an example of a network including users and content providers 
where the concept of proportional fairness is applied; • 



Figure 4 is a flowchart illustrating schematically the operation of an embodiment of 
the invention; 



25 



30 




Figure 5 is a flowchart illustrating schematically the operation of an embodiment of a 
further embodiment of the invention; and 

Figure 6 is a flowchart illustrating schematically the operation of yet a further 
5 embodiment of the invention. 

Background of the Preferred Embodiments 

In the preferred embodiment described below, reference is made to transmission of 
video data. However, the invention is not limited in this respect and may be applied 
10 to the transmission of any data. As mentioned above, the present invention has 
particular application to real time data such as video, audio data as well as interactive 
and multiparty applications. 

Figure 1 shows an internetwork comprising a content provider's local area network 1 
15 connected to a customer end configuration via an internet service provider's (ISP) 

network 6. The content provider's local area network 1 includes a video server 4 

having a stream adaptation module 24 and a memory 26 where the video data is 

stored. It is not essential that the memory 26 be located at a particular video server. 

The memory 26 may be remote from the server 4. 
20 The customer end includes a video player 2 and a dynamic price handling module 8, 

and a portion of the global Internet 6 which interconnects the user with the content 

provider. 

The internetwork in Figure 1 is suitable for use with methods for controlling 
25 congestion, such as congestion based pricing. The congestion level in the network is 
signalled to the user, for instance, by using the explicit notification protocol (ECN). 
The ECN protocol is standardised as part of the IETF Standard Track as RFC 
3168[2T], and is the subject of the Market Managed Multiservice Internet (MSI) 
Consortium, a multi party collaboration including the applicants. For more information 
30 on the MSI Consortium reference is made to http://www.m3i.org. 

When a user sends a request for a download of data to the content provider, the 
internetwork shown in Figure 1 responds as described below. The content provider 




receives the request and when the data is ready for transmission begins to transmit 
data to the user via the network. The network provider linking the content provider to 
the user randomly mark data packets on its network. The larger their data rate, i.e. 
the number of packets per unit time, the higher the probability will be that a packet is 
5 marked. Thus the number of marked packets received at the user end will be 
indicative of congestion level. Marking of data is done in accordance with the explicit 
congestion notification protocol, which has been standardised as part of the IETF 
Standard Track as RFC 3168[21]. 

10 The marks In the data are detected at the user end of the network by a metering 
module 14. The location of the metering module 14 is not important provided It Is 
disposed between the content provider and the user. For example, it may be disposed 
within the network or at the user's end. 

15 The metering module 14 produces an estimate of the marking rate for the data 
destined for the user, which is the ratio of marked packets among the received 
packets over an observation period. 

The user is charged an amount for each marked packet in the data stream received. 

20 This charge may bear a real monetary value and later be used to actually charge the 
user. Alternatively, the price per mark may also remain a fictional charge and simply 
represent an Indication of the amount of data on the network, i.e. the level of 
congestion. If there is enough traffic with one user on the connection, then the 
number of marks will be an Indication of the congestion on the network, that is the 

25 total amount of traffic on the network. Thus the congestion Indication may represent 
a symbolic Incentive for the user to reduce her consumption of the network's 
resource. In any case, the marking rate reflects the current congestion level in the 
network and is the main dynamic input to the control means 18 at the user's end to 
the control the data rate of the connection and thereby optimise the utility of the 

30 customer. The price charged by the network is proportional to the congestion level. 
The charge for the user is based on the product of the price charged by the network 
and the amount of data sent or received by the user. 
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Detailed Description of the Embodiments 

The present invention is preferably embodied in a rate controller 1 6, comprised within 
a dynamic price handling (DPH) agent 8. In the example, shown in Figure 1, the DPH 
5 agent is located at the user's end. This arrangement is preferable, however, the 
invention is not limited in this respect, and the DPH agent 8 may be located 
anywhere within the Internetwork provided the user's preferences can be input to it, 
and provided its output can be transmitted onto the network. In particular, DPH may 
be located at the content provider's end. 

10 

The role of the DPH is to perform the rate control of the data stream the user is 
interested in. When the user sets up a connection she specifies her control policy 32. 
Then for the duration of the connection, the DPH monitors the evolution of the 
marking rate 30 and - when necessary - requests that the data rate delivered to the 
15 user over the network to be adjusted to a new target rate 36. The delivery process 
itself may be carried out according to any method as long as it provides a working 
interface for rate control purposes. The improvement achieved by the present 
invention is to have a configurable rate control based on the congestion marks 
signalled by the network rather than a default rate control based on packet losses. 

20 

The marking rate is retrieved from the metering module 14, it represents the 
proportion of marked packets within the data stream during a period and is expressed 
in marks per packet. This period will not necessarily be the same for input to the 
price reactor 18 and to the rate controller 16. 

25 

The adjustment request from the rate controller is communicated to the server 4 via 
the quality of service controller 12 of the video client 2 over the control channel 38. 
The stream adaptation module 24 of the video server will adjust the data sent to the 
user accordingly. 

30 

The DPH agent 8 is now described in greater detail. Within the DPH agent 8 three 
main functions are performed : the policy selection, the price reaction and the rate 
control. While the policy selection is done mainly before the service is delivered to 
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the customer, the price reaction and rate control are carried out during the duration 
of the connection, it may also be updated occasionally as the service is provided. The 
price reaction and rate control however, are performed continually while the service 
is being delivered, with the price reaction preferably, being performed on a longer 
5 timescale than rate control. 

When a connection is set up for download of data to a user, the user defines her 
strategy, i.e. how she will react to changes in the congestion indication (or 
congestion price). This is done by selecting a buying policy reflecting her needs using 

10 the policy selector 20. A default policy, or more usually a selection of popular or 
commonly used policies, is provided by the content provider when the connection is 
set up, but the user is able to customize her buying policy to accommodate her 
preferences. The buying policy defines the demand function 32 of the user, and is 
used by the price reactor to determine the requested data rate. The demand function 

15 is the relationship between a given congestion indication (or congestion price) and 
the data rate the user is willing to accept for that congestion indication. Having 
selected a buying policy, the DPH agent is able to handle the transmission control on 
behalf of the user for the rest of the session. If the user wishes, however, the buying 
policy may be changed during the session. 

20 

The policy selector allows the user to define how she would like the DPH to react to 
the congestion signal by choosing an adequate user policy. The user will always have 
to choose her policy when the connection is set up and she may modify or change it 
during the session. The default policy is adopted if the user does not want to 
25 configure the DPH. The user policy is the only input the DPH needs from the user to 
handle the rate control of the connection on the user's behalf. 

The policy selector 20 translates the user policy into a demand function 32 that gives 
the optimal rate the DPH should request for any congestion shadow price. A typical 
30 demand function is a decreasing function of the congestion price : the more 
congested the network, the less the user is willing to create traffic. In the 
implementation of the DPH, the decreasing function is represented as a set of points 
that give the value of the demand function for a number of values of the congestion 
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price. The value of the demand function 32 for other congestion prices is obtained 
by linear interpolation. 

The price reactor module 18 periodically establishes the willingness to pay 34 of the 
user according to the user's demand function 32 obtained from the policy selector 
20, and to the marking rate 30 reported via the metering module 14. In addition, the 
price reactor 18 infers an estimate of the congestion shadow price in the network 
from the marking rate 30 reported via the metering module 14. This estimate reflects 
the congestion level in the network. 



10 



The function of the rate controller 16 is to reach the optimal transmission data rate 
as smoothly as possible to avoid compromising the stabilrty of the network. 
Consequently, the rate control module 16 monitors the congestion indication (or 
congestion price) on a shorter timescale than the price reactor 18 does. This is 
1 5 achieved using the rate control algorithm of the present invention, described in detail 
below 

In the embodiment shown in Figure 1, the rate controller 16 determines which 
streaming data rate is to be requested, and communicates it to the quality of service 

20 controller which is embedded in the video player 1 2, which sends a request message. 
The decision to request a data rate adaptation is performed by the quality of service 
controller, which sends a request to the content provider. However, it is not essential 
that the quality of service controller handles the communication to the content 
provider's server. The rate controller 1 6 may also communicate the request data rate 

25 to the content provider. 

Figure 1 also shows the main components of the DPH agent 8 and how they 
interface together. The policy selector 20, with which the user interacts. Inputs the 
demand function 32 to the price reactor 1 8 at the start of the session. During the 
30 whole duration of the session, the marking rate 30 is communicated to the price 
reactor 18 and the rate controller 16. At regular time intervals, the price reactor 18 
updates the willingness to pay 34 which is communicated to the rate controller 1 6. 
Periodically, according to the willingness to pay and the congestion price estimate 
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(determined from the marking rate), the rate controller selects a new target data rate 
36, which the rate controller 1 6 or quality of service controller communicates to the 
content provider. Overall, the DPH agent 8 therefore, determines the adaptation 
signal for the data rate on the connection from the congestion indication signalled by 
5 the marking rate. 

The dynamic inputs to the DPH agent 8 are the marking rate, the price per mark and 
the demand function which includes the willingness to pay. However, usually, the 
price per mark and the demand function will not vary during a session. 
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The marking rate is retrieved from the metering module 14 and represents the 
proportion of marked packets within the data stream during a period. This period will 
not necessarily be the same for the input to the price reactor 18 and to the rate 
controller 16. 
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The demand function 32 is communicated from the policy selector 20 to the price 
reactor 1 8. The price reactor 1 8 determines the optimal streaming rate in bits per 
second for a set of discrete values of the congestion indication in marks per bit. The 
value of the demand function .32 for any congestion price is obtained by linear 
20 interpolation. 

The willingness to pay 34 is determined by the price reactor 18 and communicated to 
the rate controller 1 6. 

25 The target rate 36, expressed in bits per second, is preferably communicated to the 
quality of service controller 1 5 for further communication to the stream adaptation 
module 24 at the content provider's server 4. 

With respect to the components of the DPH agent, the following additional 
30 description is given. 
The policv selector 

The policy selector 20 produces the user's selected policy which contains the 
demand function of the user, inferred from the utility function. For further details on 
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how the demand function is extracted from the utility function, reference is made to 
"S. Briscoe, "Price Reaction Design", Deliverable 3.2 (July 2000). MSI EU Vth 
Framework Project IST-1 999-1 1429 http://www,m3i-org , 

5 The demand function is the relationship between the user's optimal preferred data 
rate and the estimated congestion price. 

By way of explanation. Figure 2 shows two demand functions. Figure 2a is a demand 
function whose purpose is to demand a constant data rate regardless of the 

10 congestion price. So, however high the congestion price, the user is prepared to P^^/^^ 
in order to maintain her optimal data rate. The user policy related to this demanc^ 
function is referred to as "constant quality of service". In terms of utility function, 
the "constant quality of service" policy is a step form, i.e. the customer has no use 
of the data unless it is received completely. 

15 Figure 2b shows a demand function which is intended to keep the charging rate 
constant over a period of time (the amount of money charged to the user for the data 
transmitted over a unit of time). The policy related to this demand function is referred 
to as "constant charge". In terms of utility function, the "constant charge" policy 
corresponds to a user with a logarithmic utility for the bandwidth. It is added that the 

20 invention supports a wide variety of policies and is not limited in this respect. 

Further, any policy can be customised to accommodate a user's preference- The two 
policies discussed above, however, represent two of the most preferred policies. 

The price reactor 

25 The price reactor takes the user's policy which defines the demand function D(p) 
with respect to the shadow congestion price to determine the user's willingness to 
pay. 
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The marking rate from the metering module 14 is the primary dynamic input to the 
price reactor 18. The marking rate is evaluated by the price reactor 18 on a periodic 
basis. 
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The first step (1) is to obtain the congestion price. The congestion price, p(-), in 
charging unit per bit is inferred from the nnarking rate, nn(-), in marks per bit, and the 
price per mark,ppm, in charging unit per mark. 

5 (1) p = m*ppm, where p is the congestion price as a function of time, m is the 
marking rate as a function of time, and * hereinafter means multiplied by. 

The second step (2) is for the price reactor to determine an intermediate target rate in 
bits per second. 
10 (2) target_rate = D{p). 

The third step is to determine the willingness to pay, w, from the target rate. 
(3) w = target_rate*m. 

1 5 The willingness to pay is communicated to the rate controller. 

Rate controller 

The rate controller 16 includes a memory 17 for storing the requested data rates and 
a processor. The rate controller 1 6 determines the data rate that is to be requested to 
20 the content provider on the basis of the willingness to pay of the user, the 
instantaneous congestion price and the data rates available from the content 
provider's server 4. 

The rate controller 1 6 calculates the optimal data rate using a rate control algorithm 
25 according to the present invention. The rate control algorithm enables an optimal 
target rate to be calculated in order to adapt to changing congestion conditions 
without putting the network stability at risk. 

The rate control algorithm used by the rate controller 1 5 is: 
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(4) Xn+i = Xn + delta*kappa* Xn^w - xn*//) 
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where Xnis the current target rate in bits per second as calculated at the nth iteration; 
// is the congestion charge and is determined from the marking rate obtained from the 
metering module 1 4; w is the willingness to pay as updated by the price reactor 1 8; 
delta is the length of the metering cycle in seconds; kappa is a constant; and ^ (xi) is 
5 a parameter having a value between -1 and + 1 . ^ is discussed fully below. 

It is noted that fj in Formula (4) is used to give an indication of the congestion, and 
does not necessarily have any monetary implication. 

It is further added that kappa is constant and represents the ability of the system to 
adapt to a change in the requested data rate. Kappa, also denoted as k in the text 

10 below, is referred to as the adaptation gain, that is the nominal speed of reaction. 
The tuning of kappa reflects the compromise between reactivity and stability. The 
higher the value of kappa, the swifter the reaction of the system (at the risk of 
causing instability). The lower the value of kappa, the more stable the data rate will 
remain (at the risk of barely adapting to a different requested data rate). If, for 

1 5 example, kappa were 0, the data rate would remain constant and would not adapt in 
spite of the requested data rate. 

Formula (4) represents a discretisation of a system of differential equations 
underlying the present algorithm as discussed below, and shown below in equation 



Theoretical Background 

In order to fully appreciate the invention, some theoretical background of the rate 
control algorithm of the present invention is given in this section. 



For background, reference is made to "F P Kelly, A K Maulloo, and D K H Tan, Rate 
control for communication networks: Shadow prices, proportional fairness and 
stability. Journal of the Operational Research Society 49 (1998), no. 3, 237-252", 
which sets out the primal algorithm and the concepts of stability and fairness of a 
30 system governed by an equation based congestion algorithm. 

The inventors of the subject application have deduced that the non-time delayed 
version of the primal algorithm is globally stable and proportionally fair, but the global 
stability is not guaranteed when time lags are taken into consideration. The inventors 
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(5). 
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have found out that the kappa parameter in the algorithnn is crucial: it has to be 
sufficiently small to achieve an acceptable level of local stability. However, setting 
kappa to the low values required to attain stability, results in a painstakingly slow 
convergence, which is also not acceptable. The inventors have found, that in fact, 
5 the rate of convergence In general in the primal algorithm is problematic. The lack of 
a mechanism like the slow-start in TCP is partly responsible for these problems. (It is 
noted that the name "slow-start" in TCP is counterintuitive: during "slow-start" the 
transfer rate actually changes very rapidly, not slowly, in order that the data rate 
reaches the optimum rate as quickly as possible. This nomenclature has its roots in 
10 TCP's history.) 

The algorithm of the present invention overcomes the problems with the primal 
algorithm. It is able to operate in different phases, like "slow-start", i.e where the 
data rate changes rapidly, and congestion avoidance, i.e. where the data rate is kept 
1 5 constant. The algorithm of the present invention is referred to hereinafter as the % (xi) 
algorithm and is named after one of its parameters, which determines the "phase", 
i.e. the mode, in which the algorithm operates. 

In the sections below, the ^ (xi) algorithm is presented and, some theoretical results 
20 on its stability and fairness are derived. Also, the presence of the ^ parameter, that 
allows the algorithm to operate in different phases is discussed. This discussion 
includes the discussion of phase transitions, that is when to move from one phase to 
another. 

25 £ (xi) algorithm 

To present the % algorithm, a mathematical model is required. Let J be a set of 
network resources, and cj the (finite) capacity of resource j, for j e J . Furthermore, 
take R c P(J), the set of possible routes, and xr, r e R, the transfer rate of the flow 
through route r. 

30 Let A = (Ajr, j e J, r e R), where Ajr = 0 if j ^ r and 1 if j e r. 

A vector of transmission rates x = (xr, r e R) is feasible if x is greater than or equal 
to 0 and Ax is less than or equal to c. 
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In addition, the functions pj( ), j e J, where pj (y) is the price charged by resource j, 
per unit flow, when the total flow through resource j is y. Finally, take w = (wr , r e 
R), the amounts users are willing to pay per unit time for each route, and kappa, the 
gain factor discussed above. 

The ^ algorithm can now be described by the system of differential equations: 



(5) '^xXt)=^KxXtf 



f ^ 



1 0 where the summation is over a set of routes, and where 



(6) mjiO^pix^XO 

We* 



where the summation is over all routes s which contain resource j and where ^ is the 
1 5 reactivity parameter, as discussed below. 

It is assumed above that r ranges over R and j over the set J. 

As mentioned previously the prices pi(-) need not be prices in the strict sense of the 
20 word. The may, as mentioned, represent the level of congestion feedback from the 
network via the metering module 14. 

It is observed that when ^ = 0, the behaviour of the ^ algorithm is identical to that 
of the primal algorithm. However, when ^ is set to a value greater than zero, the 
25 algorithm is more aggressive than a standard additive increase, multiplicative 
decrease (AIMD) algorithm, and more resembles TCP's behaviour during "slow-start". 
On the other hand, when § is less than zero, the transfer rate is kept almost 
constant, changing very slowly indeed. A more detailed analysis of how the 
algorithm's behaviour depends on ^ is given below. 

30 
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Stability and Fairness of the ^ algorithm 

Stability and fairness are two important criteria applied to congestion algorithms to 
assess their performance. 

An algorithm is regarded as being stable if it has a stable operating point, that is a 
5 situation in which the transfer rate is kept constant under constant network 
conditions. An algorithm is regarded as having global stability if the stable operating 
point is reached automatically after a certain amount of time. Furthermore, an 
algorithm is regarded as having local stability if, after a stable situation has been 
reached, small perturbations of the network conditions, do not affect the stable 
10 operating point. And finally, assuming that an algorithm will converge to a stable 
operating point, what is the rate of convergence, that Is how long does it take 
before a stable situation is reached. 

The concept of fairness pertains to situations where a number of flows share 
15 network resources. In real life situations, these resources are generally limited. 
Fairness is concerned with each flow getting its "fair share" of the available 
resources. What exactly is meant by "fair" depends on the sort of fairness used, as 
there are different criteria for assessing fairness. The type of fairness used to assess 
the ^ algorithm is proportional fairness. 

20 

The inventors have shown that the ^ algorithm exhibits good stability and fairness. 
These two properties were considered by Kelly et al in "F P Kelly, A K Maulloo, and D 
K H Tan, Rate control for communication networks: Shadow prices, proportional 
fairness and stability. Journal of the Operational Research Society 49 (1998), no. 3, 
25 237-252". The inventors have applied the criteria of stability and proportional 
fairness defined in Kelly et al's paper to the § algorithm. 

In order to appreciate how the stability of the § algorithm has been determined 
theoretically, Lyapunov's second method is referred to. For the sake of completeness 
30 a brief discussion of Lyapunov's second method is given below. Reference is made to 
"William E Boyce and Richard C DiPrima, Elementary differential equations and 
boundary value problems, 6**" edition, John Wiley & Sons, Inc" for a fuller explanation 
of this method. 
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Lyapunov's second method is used to establish the stability or otherwise of systems 
of differential equations, such as those set out above* in equations (5) and (6) 
representing the present invention, and is as follows: 
Given an autonomous system of differential equations 



and a function V{x), defined on some domain D containing the origin, define the 
function F: 

<r dV dV dV 

(8) j^^)^^^jc)F,{x)^^^ 

cocj (3x^ 

10 Note that f^depends on the system of differential equations set out in equations (7). 
For convenience, the following definition is introduced: 

Lyapunov function: consider the system of differential equations (7) and assume that 
it has an isolated critical point x. A function F(jc) that is continuous, has continuous 

partial derivatives, has a global maximum at x, and for which V(jx — x) is positive 
15 definite on some domain D containing the origin, is called a Lyapunov function for 

the autonomous system represented by equations (7). 

Using this definition the following theorem can be stated (proof omitted): 

Theorem 1 : suppose that the autonomous system represented by equations (7) has 

an isolated critical point x. If there exists a Lyapunov function V for this system, 
20 then x is an asymptotically stable critical point. If the function V(x — x) given in the 

definition above is positive semidefinite instead of positive definite, then the origin is 

a stable critical point. 

To assess the stability of the 4 algorithm Kelly's approach was used. Thus, the 
25 following formula is defined: 

(9) U(x)^^wM^,^^ \pj(y)dy 



Where U(x) is the user's utility function, from which the demand function, as 
discussed above, is derived. 
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It is assumed that wr > 0, r € R, and that for j e J the functions pj(y), where y > 0, 
are non-negative, not identically zero, continuous, and increasing. 

The following Theorem 2 is proposed: the continuous, strictly concave function U(x) 
5 is a Lyapunov function for the system of differential equations (5) and (6). The 
unique value x maximising U(x) is an asymptotically stable point of the system. 

The following proof is given: it follows from the assumptions on Wr, r e R , and pj, j e 
J, that Uix) is strictly concave on x>.0 with an interior maximum. Hence, the 
10 maximising value of x, which we shall call x, is unique. 

Observe that U has continuous partial derivatives, and that 
(10) 



establishing Xhat—U{x(t)-x) is a positive definite on some domain containing the 



It is thus shown that U \s a Lyapunov function for the system represented by 
equations (5) and (6). 
20 Application of Theorem 1 yields the second part of the Theorem. 

To assess the fairness of the 4 algorithm the following Kelly definition of proportional 
fairhess was used. 

Suppose that the network has a set of J resources, and let be the finite capacity 
25 of resource j\ for j g J. Further more, take R^P{J), the set of possible routes, and 
x^,r^R the transfer rate of the flow through route r. Finally we define 
A^{Aj,J € J,r e i?), where 
{1 1 ) Ajr = 0 if 7 0 r and 1 if y € r . 
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origin. 




A vector of sending rates x=^(x^,r e R) is feasible if a:>0 and Ax^c. 
Proportional fairness is defined as follows: A vector of rates x is proportionally fair if 
it is feasible, and if for any other feasible vector x, the aggregate of proportional 
changes is zero or negative: 

5 

(12) 2;^^^<o. 

Without showing proof, the following Theorem 3 is stated from "Jean- Yves Le 
Boudec, Rate adaptation, congestion control and fairness: A tutorial.''. 
10 Theorem 3: For every network situation there exists a unique proportionally fair 
allocation. It is obtained by maximising ^Inx^ 

Theorem 3 is particularly useful because it gives a practical way of computing a 
proportionally fair allocation. Simply maximising the function ^Injc^ suffices 

reR 

Figure 3 illustrates proportional fairness using a network with two resources 300, 
15 302 and three users 304, 306 and 308. Both resources 300, 302 have capacity 12 
(arbitrary units). The proportionally fair allocation is shown: user 304 has 4 units, 
users 306 and 308 have 8 units. Proportional fairness gives priority to small flows. 
An extension to the proportional fairness concept is the idea of weighted proportion 
fairness. The definition is as follows: A vector of rates x is proportionally fair if it is 
20 feasible, and if for any other feasible vector x, the aggregate of weighted 
proportional changes is zero or negative: 

(13) S^^.^^^^O 

reR ^r 

with M^ = (w^,r e R) a vector of weights, n.b. w here is not to be confused with the 
willingness to pay, shortened to w. 
25 Theorem 3 can be adapted to cover weighted proportional fairness. It is now 
necessary to maximise ^^w^\ax^ It is to be noted that the uniqueness of the 

reR 

solution is not guaranteed any longer, but depends on the weighting vector, w. 




Theorem 4: the functions pjj e J, may be chosen such that the vector x 
maximising U{x) approximates arbitrarily closely a vector of rates that is weighted 
proportionally fair, with vector of weights w. 

The following proof of Theorem 4 is given: let the functions pjJ e J, be defined as 

where pj is a price function and s dictates the slope of the price functions. (The 
superscript + indicates that if the quantity within the brackets has a negative value, 
then it takes the value zero, and if the quantity within the brackets is positive, then it 
keeps its positive value.) 
10 These functions are continuous. As e->0, the vector maximising U{x) approximates 
arbitrarily closely the solution of the fairness problem 

(15) max^w^lnx^ 

subject to Ax<c over jc>0. 
1 5 Hence, by Theorem 3, set out above, x is proportionally fair per unit charge. 

It is important to note that both Theorems 2 and 4 remain valid when a different 
value for ^ is taken for each route or user, that is taking ^ =^,.),r e R instead of just 
^■ 

20 

The £ algorithm and phases 

The. ^ algorithm has the distinct advantage over other equation based congestion 
algorithms depending on its implementation discussed below, of weighting the data 
rate to be requested by a variable parameter, This enable, for example, the % 

25 algorithm to operate in different phases, i.e. depending on the network conditions at 
a particular time, its reaction to the particular conditions will be different, allowing it 
to adapt, and to ultimately cause data in the network to be handled more efficiently. 
The phase of the algorithm is determined by the value of The switching from one 
phase to another depends on network and user defined conditions. The present 

30 invention based on an assessment of these conditions causes the phase switch to 
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occur automatically, to thus ensure a more efficient resource management. An 
embodiment showing the phase switch is shown in Figure 5. 

In the embodiment discussed below with reference to Figure 4, ^ is a weighting 
variable parameter. 

5 In the embodiments discussed below with reference to Figure 5, ^ takes one of two 
values depending on the network conditions and the user's willingness to pay. ^ is 
not however, limited in this respect and can take an infinite number of values. In this 
section the behaviour of the ^ algorithm is observed with respect to a limited small 
subset of examples where ^ has the value 0, -1 and +1. Also discussed in this 

10 section are the network and user defined conditions which apply to cause the 
algorithm to switch phases, ie. the conditions that apply to cause ^ to change value. 
By responding to network conditions, the change in the selection of the value of ^ 
will change the behaviour of the network, and in particular, as discussed above with 
reference to Figure 1 and below with reference to Figure 5, the requested data rate 

1 5 that is sent to a content provider. 

In the first of the examples, § is selected to be equal to zero. When ^ = 0, the 
algorithm behaves in the same way as the primal algorithm. 

20 In the second example, 4 is set to be equal to + 1 . It was mentioned earlier with 
reference to the prior art, that one of the problems of the primal algorithm is slow 
convergence due to the absence of a mechanism like slow-start in TCP. Setting ^=1 
solves this problem: it provides a phase in which the transfer rate increases 
exponentially. This causes the algorithm to act "aggressively" to generate rapidly 

25 changing data rate requests which are sent to the content provider. This phase is 
particularly useful at the beginning of a data download, where the user will want to 
go from zero data rate request to a stable downloading data rate as quickly as 
possible. 

The proof in Theorem 4 with respect to the stability does not depend upon the value 
30 of ^, so in theory the aggressive rate control strategy that is the result of setting ^ to 
+ 1 does not compromise stability. 
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In the third example, ^ is set to -1. Whereas 4= 1 results in aggressive rate changes, 
setting §=-1 has exactly the opposite effect: the transfer rate will be adapted 
extremely slowly. This means that the convergence will be slow, but once equilibrium 
is reached, small perturbations will have little or no effect. In other words the local 
5 stability will be extremely good. This situation is very desirable for some applications, 
notably real-time video or audio streams. Thus, this phase is very useful in situations 
where no drastic adaptation of the transfer rate seems to be required, and the only 
changes are due to small perturbations in shadow price information around an 
equilibrium. 

10 

The present invention allows for the possibility of setting ^ to 0 or +1 when 
relatively rapid changes of data rate request are required, for example to get 
sufficiently fast convergence, while setting ^ = -1 at other times to satisfy the needs 
of several different types of applications, for example, real time data download 
1 5 applications and multimedia applications. 

The invention is not limited with respect to what determines the value of ^. For 
example, however, one set of parameters to apply when changing ^=1 or 0 to ^ = -1 
is in response to the marking rate which gives rise to congestion indication and the 
20 price charged by the network. When that price is within a tolerance parameter, beta, 
close to the price the user is willing to pay, ^ can be set to -1 because when the 
price charged is more or less the same as the price the user is willing to pay, the data 
rate request should be kept as close to the user's willingness to pay as possible. This 
mechanism is explained in more detail with reference to Figures 4 and 5. 

25 

A preferred implementation of the invention is in software: the rate controller 1 6 acts 
as a single middleware that runs in the background on a user's machine. It captures a 
user specified buying policy from the policy selector 20 along with the real-time 
dynamic pricing information from the marking module 14 and produces a requested 
30 data rate using the ^ algorithm described above. 

The form in which the ^ algorithm was present above, as a system of differential 
equations, makes it unsuitable to be implemented in software directly. Computers 
provide a discrete environment and cannot cope with the inherently continuous 
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nature of a differential equation. To Implement the invention in software, it is 
therefore necessary to include a discretisation step and to transform the differential 
equations into difference equations. 

This results in equation (4), which may also be written as the following system: 
(16) 



where 



m 



r \ 

\s:Jes > 



and S is the discretisation step size. Other techniques for solving differential 

equations numerically, for example numerical integration, could also be used. 

The step size 5 is important. It should not be too small, because of restrictions on 

10 computing power and the availability of price feedback, but a step size that is too 
large will result in errors. Preferably, the step size 5 is chosen in accordance with the 
frequency of the price feedback availability. This will vary from network to network 
depending on the marking rate in the network. The period over which marks are 
collected and counted should not be too short, for then the number of marks will 

1 5 always be either 0 or 1 , or perhaps a little higher, and most of the price information 
will then be conveyed by the number of marks in any one period. On the other hand, 
from the point of view of the rate control algorithm, it is desirable to have price 
feedback as frequently as possible. 

20 Those skilled in the art will have no difficulty in providing a program to collect the 
parameters discussed above, applying the algorithm to those parameters to generate 
the network resource control described above, and shown step by step in Figures 4 
and 5. 



25 The procedure for implementing resource control using the rate controller of the 
present invention is shown in Figures 4 and 5. The rate controller 16 functions 
according to the § algorithm shown in equations (4) and alternatively notated in 
equation (16). 
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As mentioned above, the rate controller 1 6 preferably forms part of the DPH agent 8 
shown in Figure 1 . 

With reference to Figure 4, at step 41 , the Indication of the congestion is obtained. In 
5 step 42, the willingness to pay is selected in response to the price reactor as 
described with reference to Figure 1. In step 43 the dynamic input values are 
retrieved: the data rate, xn is retrieved from the memory 17 in the rate controller 16 
and the indication of congestion is obtained from the price reactor 1 8 if not already 
retrieved. In step 58, the difference, D, between the willing ness to pay and m*Xn is 
10 computed. In step 44, the data rate to be requested is determined as a function of 
the indication of the congestion and the willingness to pay. In step 45, the output of 
step 44 Is weighted by a variable parameter, xl. 

in step 46 the data rate to be requested is communicated to the content provider. In 
particular, this is done via the stream adaptation module 24. 

15 

In step 47, it is ascertained whether or not the data transfer is complete. If it is 
complete, the algorithm ends. If the transfer is not complete, it is ascertained in step 
48 whether the willingness to pay, w, is to remain the same, or whether this user 
determined parameter is to change. If the willingness to pay is to remain unchanged, 
20 the algorithm proceeds directly to step 43 for the next iteration. If the willingness to 
pay is changed, the algorithm returns to step 41 . 

A further embodiment is now described with reference to Figure 5. At step 50 the 
adaptation gain factor, kappa, and the discretisation constant, delta, are set. As 

25 mentioned, the selection of kappa will reflect a compromise reached between 
reactivity, also referred to as convergence and stability. The higher the value of 
kappa the ampler the reaction, and the greater the risk of instability. The lower the 
value of kappa, the more stable the data rate, and the greater the risk of not adapting 
enough. The choice of the value of delta will depend on the computing resource 

30 available, the marking rate and the frequency of the price feedback. At step 50, the 
constant beta is also set. This constant is a tolerance parameter reflecting the limits 
with respect to the network determined parameter, that is the price derived from the 
congestion indicators, within which the user determined parameter, that is the 
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willingness to pay, should fall if the requested data rate is to remain stable. If the 
willingness to pay with respect to the price does fall within the tolerance parameter, 
xi is set to zero. If, on the other hand, the willingness to pay with respect to the price 
does not fall within the tolerance parameter, xi is set to 1 or to any other small 
5 positive value, to cause the algorithm to react speedily to request a higher data rate. 
The value of beta will depend on the network, and preferably lies between 1 and 
10%. For example, if beta is set to 0.05, i.e. 5%, then the values obtained in step 
60 is [0.95*w;1.05*w], or in other words, when that value differs from w by less 
than 5%, xi is set to 0 for a gentle adaptation, otherwise xi is set to 1 or a small 
10 positive value for the aggressive adaptation. In the particular example given above, 
the value of xi is a step function, however, how xi varies is not limited, and xi may 
also vary continuously, for example, with the difference between the price and the 
willingness to pay. 

The values kappa, delta and beta do not have to remain fixed throughout the session 
15 or download. However, usually, they will remain fixed during one session. 

In step 52, the price estimate, ^i, also referred as the congestion charge, is retrieved 
from the price reactor. It is noted that the price estimate \i may also be referred to as 
the congestion charge. In step 54 the willingness to pay, w, is set in response to the 
20 price reactor as described with reference to Figure 1. In step 56 the dynamic input 
values are retrieved: the data rate, Xn is retrieved from the memory 17 in the rate 
controller 16 and the price estimate, m, from the price reactor 18 if not already 
retrieved. In step 58, the difference, D, between the willingness to pay and |a*Xn is 
computed. The product of ^*Xn is the indication of congestion. 

25 

In step 60, it is established whether the difference, D, lies within the range 1-beta*w 
and 1 +beta*w. If D does lie within the range then xi is set to 0 in step 64. If D does 
not lie within the range, xi is set to 1 or a small positive value in step 62. Once xi is 
set, the next step 66 is to compute the difference, D, multiplied by Xn to the power 
30 xi, that is D* xn^. In step 68, the output from step 66 is multiplied by the gain factor, 
kappa, and the time step, delta. In step 70, the output from step 68 is added to the 
data rate, Xn, to obtain the requested data rate, Xn+i. In step 74, the rate controller 
memory 17 is updated. Xn is replaced with Xn+i, and set as Xn. In step 72 the data 




rate to be requested, Xn+i, Is communicated to the content provider. In particular, this 
is done via the stream adaptation module 24. This may be communicated to the 
stream adaptation module via the quality of service controller 15. 



5 In step 76, it is ascertained whether or not the data transfer is complete. If it is 
complete, the algorithm ends. If the transfer is not complete, it is ascertained in step 
78, whether time step, delta, has elapsed since this step was last carried out. if the 
time period, delta, has not elapsed, the algorithm waits until it has. If the time period 
has elapsed, in step 80, it is ascertained whether the willingness to pay, w, is to 
10 remain the same, or whether this user determined parameter is to change. If the 
willingness to pay is to remain unchanged, the algorithm proceeds directly to step 56 
for the next iteration. If the willingness to pay is changed, the algorithm returns to 
step 52. 



15 With reference to Figure 6 the procedure for implementing resource control according 
to a different algorithm using the rate controller is shown. The rate controller 16 is 
comprised in the DPH agent 8 as for the previous algorithm and as shown in Figure 
1 , but generates a request for data rate according to a different algorithm. 

20 As with the xi algorithm, the algorithm is a discretisation of a system of differential 
equations. Hereinafter the algorithm, whose procedure is shown in Figure 5 is 
referred to as the scalable algorithm. 
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The system of differential equations representing the scalar algorithm is; 



(17) 4^.(0 = K 
at 



wtpXt) 



for r € i2. 

This system of differential equations was developed from the willingness to pay (w). 
As mentioned previously, the willingness to pay represents the amount a user is 
30 willing to pay for the service provided by the network. In general this amount can 
vary over time, so willingness to pay becomes a function of time. The scalar 
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algorithm, rather than taking a single data stream, describes the overall behaviour of 



the network. 

Again, as with the xi algorithm, the form in which the scalar algorithm was presented 
5 above in equation (17), as a system of differential equations, makes it unsuitable to 
be implemented in software directly. Computers provide a discrete environment and 
cannot cope with the inherently continuous nature of a differential equation. To 
implement the invention in software, it is therefore necessary to include a 
discretisation step and to transform the differential equations into difference 
10 equations. 

This results in equation (18), which may also be written as the following system: 



where the parameters are the same as those referred to above with respect to the xi 
15 algorithm. 

The advantage of a rate controller implemented according to the scalar algorithm is 
that the convergence properties depend only on the relative variation of the 
congestion charge Ot/), that is, it will take as long to settle to the new equilibrium 
when the congestion level goes from 9% to 12% as when the congestion goes from 
20 3% to 4%. 

The implementation of this algorithm is now described with reference to Figure 5, 
At step 90, the gain factor, kappa, and the time step, delta, are set. At step 92, the 
price estimate is retrieved from the price reactor 18. At step 94, the willingness 

25 to pay (w) is set in response to the price estimate (m). At step 96 the dynamic input 
values are retrieved. The data rate (Xn) is retrieved from the memory 17 in the rate 
controller 1 6 and the price estimate ifj) is retrieved from the memory of the price 
reactor 18. At step 98, the difference (D) between the willingness to pay (w) divided 
by the price estimate (//) and the data rate (xn) is computed. At step 100, the output 

30 from the previous step 98 is multiplied by the gain factor (kappa) and the time step 
(delta). A step 102, the output from previous step 100 is added to the data rate (xn) 
to obtain the request data rate (xn+i). At step 104 the memory 17 in the rate 





controller 16 is updated. Xn is replaced with Xn+i- At step 106, the value of Xn+i is 
communicated to the stream adaptation module 24. At step 108, it is ascertained 
whether the data transfer is complete. If it is complete, the program stops. If it is not 
complete, at step 110, it is ascertained whether time step, delta, has elapses since 
5 this step was last carried out. If the time period, delta, has not elapsed, the algorithm 
waits until it has. If the time period has elapsed, in step 1 1 2, it is ascertained 
whether the willingness to pay, w, is to remain the same, or whether this user 
determined parameter is to change. If the willingness to pay is to remain unchanged, 
the algorithm proceeds directly to step 96 for the next iteration. If the willingness to 
10 pay is changed, the algorithm returns to step 92. 

Unless the context clearly requires otherwise, throughout the description and the 
claims, the words "comprise", "comprising" and the like are to be construed in an 
inclusive as opposed to exclusive or exhaustive sense; that is to say, in the sense of 
1 5 "including, but not limited to". 
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CLAIMS 

1 . A method of controlling the rate of data transmission from a source of data 
to a user via a communications link, wherein processing means are provided to 

5 generate a signal representing a rate request which will be used in determining the 
rate at which data will be transmitted from the source to the user, said processing 
means generating the signal by carrying out the steps of: 

obtaining an indication of the amount of congestion on said communications link, 

10 selecting a value indicative of the user's willingness to pay for a given transmission 
data rate; and 

determining the rate to be requested as a function of the indication of the amount of 
congestion and the user's willingness to pay weighted by a variable parameter, the 
1 5 processing means thereafter communicating the signal to the source of data and the 
rate of the data transmission from the data source to the user then being controlled 
on the basis of the signal. 

2. A method according to claim 1, wherein said variable parameter assumes 
20 discrete values. 

3. A method according to claim 1, wherein the value of said variable parameter 
varies continuously, 

25 4. A method according to claim 1 , wherein the indication of congestion is the 
product of a congestion charge and a previously determined data transmission rate. 

5. A method according to any of the preceding claims, wherein the value of 
said variable parameter varies in accordance with the difference between the user's 

30 willingness to pay and the indication of the amount of congestion. 

6. A method according to any preceding claim, wherein said rate to be 
requested is determined using the following iterative equation: 
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Xn+l = Xn + delta* kappa* Xn^{W - Xn*//) 

where Xn is the data transmission rate (bits per second) as calculated at an nth 
5 iteration; and xn+i is the rate to be determined; xn*// is the charge to the user 
indicative of amount of congestion and is the product of Xn and congestion charge ij; 
w is the willingness to pay ; delta is the time elapsed between two iterations; kappa 
is a constant gain parameter; and ^ (xi) is a parameter whose value is set depending 
on the indication of congestion or the user's willingness to pay. 

10 

7. A method according to claim 5, wherein If the difference between the 
indication of the amount of congestion and the user's willingness to pay falls within a 
predetermined range a first data rate is requested, and if the difference between the 
indication of the amount of congestion and the user's willingness to pay falls outside 

15 the predetermined range a second different data rate is requested. 

8. A method according to claim 7 wherein said parameter ^ is a step function 
assuming the value 0 for values of said difference larger than a threshold value, and 
assuming the value 1 for values of said difference smaller than said threshold value. 

20 

9. A method according to claim 7 said step of providing an indication of amount 
of congestion includes determining a marking rate m of incoming data transmitted on 
said communications link and wherein said congestion charge is determined from said 
marking rate. 

25 

10. A rate controller for controlling the rate of data transmission from a source to 
a user via a communications link, said rate controller including processing means for 
generating a signal representing a rate request which will be used in determining the 
rate at which data will be transmitted from the source to the user, said processing 

30 means including 

means for obtaining an indication of the amount of congestion on said 
communications link. 



35 



selecting means for selecting a value indicative of the user's willingness to pay for a 
given transmission data rate, 

determining means for determining the rate to be requested as a function of the 
indication of the amount of congestion and the user's willingness to pay weighted by 
5 a variable parameter, the processing means further including means for 
communicating the signal to the source, wherein the rate of the data transmission 
from the source to the user is controlled on the basis of the signal. 

11. A rate controller according to claim 10, wherein said determining means is 
10 adapted to, determine the difference between the user's willingness to pay and the 

indication of the amount of congestion, and vary the value of the variable parameter 
in accordance with the difference. 

1 2. A rate controller according to claim 1 1 , wherein said determining means 
1 5 determines a first rate to be requested if said difference between the indication of the 

amount of congestion and said selected value falls within a predetermined range, and 
a second different data rate to be requested if the difference between the indication 
of the amount of congestion and the value falls outside the predetermined range. 

20 13. A rate controller according to any of preceding claims 10-12, wherein said 
determining means is adapted to determine said rate to be requested using the 
following iterative equation: 

Xn+1 = Xn + delta* kappa* Xn^{W - Xrx*/J) 

25 

where Xn is the data transmission rate (bits per second) as calculated at an nth 
iteration and Xn+i is the rate to be determined; Xn*// is the charge to the user 
indicative of amount of congestion and is the product of Xn and congestion charge //; 
w is the willingness to pay selected by selecting means in response to a determined 
30 transmission rate; delta is the time elapsed between two iterations; kappa is a 
constant gain parameter; and ^ (xi) is a parameter whose value is set depending on 
the indication of congestion or the user's willingness to pay. 
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14 A rate controller according to any of preceding claims 10-13, wherein said 
means for obtaining an indication of the amount of congestion comprises metering 
means for determining a marking rate of incoming data transmitted on sa.d 
communications link. 

15. A rate controller according to any of preceding claims 11-14, wherein said 
variable parameter Is a step function assuming the value 0 for values of said 
difference larger than a threshold value, and assuming the value 1 for values of sa.d 
difference smaller than said threshold value. 
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16. A method of controlling the rate of data transmission from a source of data 
to a user via a communications link, wherein processing means are provided to 
generate a signal representing a rate request which will be used in determining the 
rate at which data will be transmitted from the source to the user, said processing 
1 5 means generating the signal by carrying out the steps of: 

obtaining an indication of the amount of congestion on said communications link, 
selecting a value indicative of the user's willingness to pay for a given transmission 
data rate, 

determining the rate to be requested on the basis of the ratio of said value to said 
20 indication of the amount of congestion on said communications link. 

17. A method of controlling the rate of data transmission according to claim 16 
wherein said rate to be requested is determined using the following equation: 



25 x„^i = ^„+5 



)*K* — -x„ 



where x„ is the data transmission rate (bits per second) as calculated at an nth 
iteration and x„.i is the rate to be determined; u is the congestion charge indicative 
of amount of congestion; w is the willingness to pay; delta is the time elapsed 
30 between two Iterations; and kappa is a constant gain parameter. 
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1 8 A rate controller for controlling the rate of data transmission from a source to 
a user via a communications linlc, said rate controller including processing means for 
generating a signal representing a rate request which will be used in determining the 
rate at which data will be transmitted from the source to the user, said processing 
5 means including 

means for obtaining an indication of the amount of congestion on sa.d 
communications link, 

selecting means for selecting a value indicative of the user's willingness to pay for a 
given transmission data rate, 
10 determining means for determining the rate to be requested as on the basis of the 
ratio of the user's willingness to pay to said indication of the amount of congest.on 
on said communications link, the processing means further including means for 
communicating the signal to the source, wherein the rate of the data transmission 
from the source to the user is controlled on the basis of the signal. 
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19 A rate controller according to claim 18 wherein said determining means is 
adapted to determine said transmission data rate using the following equation: 



20 whsre x. is the data transmission rate (bits per second) as calculated at an nth 
iteration and is the rate to be detern,ined; , is the congestion charge indicative 
of amount of congestion; w is the willingness to pay; delta is the time elapsed 
between two -iterations; and lappa Is a constant gain parameter. 

25 20 A program storage device readable by a processing apparatus, said device 
embodying a program of instmctions executable by the processor to perfom, the 
steps of any one of the method claims 1 to 9 or 1 6 to 1 7. 
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ABSTRACT 

NETWORK RESOURCE CONTROL 

A method of controlling the rate of data transmission to a user via a communications 
5 link of a network wherein resource requests are communicated to a service provider. 
The resource requests are determined in accordance with an Indication of the 
congestion level on the network and the user's defined parameters, such as their 
willingness to pay for the resource, wherein the resource request is weighted by a 
variable parameter, whose value is set in accordance with the congestion level on the 

10 network. This allows the rate controller to react efficiently and swiftly to network 
conditions as well as user defined parameters. By providing a computer programmed 
to act as a purchasing agent an automatic resource request to a service provider is 
enabled. An embodiment is described in which audio or video data is streamed to a 
user on the basis of the resource requests made on the user's behalf and is adjusted 

15 on the basis of user and network defined parameters. The invention could equally be 
used to provide appropriate data streaming for many different types of network 
traffic. 

Figure 1 
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